This morning I finally found some time to add an init script to the Debian package of mysql-proxy (0.6.1-3 which includes it was just uploaded to unstable, I will try to get a freeze exception for lenny). It is disabled by default, because mysql-proxy is quite useless without a proper configuration. It can be enabled in /etc/default/mysql-proxy, here is an example:

ENABLED="true"
OPTIONS="--proxy-lua-script=/usr/share/mysql-proxy/rw-splitting.lua
         --proxy-address=192.168.1.140:3306
         --proxy-backend-addresses=192.168.1.20:3306
         --proxy-read-only-backend-addresses=192.168.1.23:3306
         --proxy-read-only-backend-addresses=192.168.1.24:3306"

In this example the proxy binds to 192.168.1.140 port 3306 and does read/write splitting. Writing statements are directed to 192.168.1.20 port 3306 (master), and reading statements are loadbalanced between 192.168.1.23 port 3306 (first slave) and 192.168.1.24 port 3306 (second slave).

Last weekend I updated the Debian package of MySQL to 5.0.67, the latest Community Edition release. It was not uploaded into the Debian archive, but is available from my home directory on gluck (amd64 only at the moment). The next Debian release lenny is frozen already, which means no newer upstream releases get accepted into testing before lenny is released, hence lenny definitely gets shipped with MySQL 5.0.51a. We will not see MySQL 5.0.67 or 5.1 in lenny, but we will continue providing backports of newer MySQL releases.

Our current primary goal regarding the MySQL packages in Debian is to get 5.0.51a in shape for lenny, so please do not send us mails asking about MySQL 5.1 or MySQL Cluster. When lenny got released we will upload MySQL 5.0.67 (or any newer community release) to unstable, and will then take care of MySQL 5.1 and MySQL Cluster.

The DRBD packages in Debian have been a bit outdated until yesterday, neither the package in unstable (8.0 branch) nor the package in experimental (8.2 branch) could be built against Linux 2.6.25. Three bugs have been filed against the DRBD packages because of that problem, which was fixed in newer upstream releases already.

After Philipp Hug accepted my offer to co-maintain the DRBD packages in Debian, I uploaded DRBD 8.0.12 to unstable and 8.2.6 to experimental. Both packages are working fine with Linux 2.6.25 and newer.

Exactly 5 years ago, on the 27th May 2003 after a discussion with my former boss an some colleagues, the domain backports.org was registered. I originally planned to write a detailed article about the last 5 years, but unfortunately didn't found the time. I'll try to catch up on this as soon as possible.

MySQL 5.1.24 was released last week. I am nearly done with preparing and testing the updated package for Debian, and will upload it to experimental within the next few days. MySQL AB decided to disable Cluster support from their official binaries with 5.1.24, but unfortunately they forgot to add a note to the release notes. It was only mentioned in a bugreport where someone asked why mysqld does no longer understand the --ndbcluster option in 5.1.24:

It was decided that we do not support NDB Cluster in the 5.1 release but do a general release of the Carrier Grade Edition 6.2 branch (which is based on MySQL 5.1) instead as it has received substantial improvements on the cluster side that can not be backported to 5.1 for now.

So while the 5.1.24 source still includes the cluster storage it is not built into the binaries released by us. A MySQL Cluster 6.2.x binary release is expected to be become available before end of April.

I am still thinking about how we should handle the new situation in Debian, hence I will keep Cluster support enabled at least for the first 5.1.24 upload. Maybe we will see a separate mysql-cluster (or mysql-cge) package in Debian soon...

MySQL 5.1 and up supports a plugin interface that allows the loading and unloading of server components at runtime, without restarting the server. Today I started working on a mysql-storage-engines package for MySQL 5.1 in Debian, which includes the PrimeBase XT and Sphinx storage engines. I currently don't plan to create separate binary packages (like mysql-engine-pbxt and mysql-engine-sphinx) for every single plugin.

Suggestions for additional plugins which should be added are welcome.

My employer IP Exchange, an internet service provider with colocations in Nuremberg, Munich and Frankfurt, is looking for three experienced Linux system administrators for our 1st and 2nd level support teams in Nuremberg.

Drop me a short mail to get the details if you're interested.

Due to hardware problems with the fibre channel controller and a read-only mounted filesystem as a result, backports.org is currently unavailable. It will last at least until tomorrow morning, just use one of our mirrors in the meanwhile.

I wanted to watch the Formula 1 Livestream from RTL on my notebook (running GNU/Linux) this morning, but it didn't work, so I took a look at the system requirements on their website:

Der Stream ist nur mit dem Windows Media Player sowie installierten und korrekt konfigurierten DRM-Komponenten abrufbar.

Thanks RTL.

Security support for Debian 3.1 (aka sarge) will be terminated on March 31st this year. We decided to terminate the security support for sarge-backports at the same time, there will be no more updates after March 31st.

Thanks to everyone who contributed to the sarge-backports archive.

Today I uploaded MySQL 5.1.23 to Debian experimental. It's currently waiting in the NEW queue for manual approval, because thanks to Monty Taylor the libndb parts are now in separate binary packages libndbclient3 and libndbclient-dev. Until it's getting approved to experimental, the updated package is available (amd64 only) from my home directory on gluck.

Last week I uploaded MySQL 5.0.51a-1 to Debian unstable. Usually not worth a separate blog entry, but in this release I included the patch for MySQL bug #4541, which was opened more than three years ago. The problem results in an error like this, e.g. when migrating a database from latin1 to utf8:

Specified key was too long; max key length is 1000 bytes

The patch from Ingo Str wing now included in Debian raises the maximum key length to 4005 bytes or 1001 UTF-8 characters. It will not go into the official MySQL source repositories because it results in bigger buffers and as such increases memory footprint and decreases performance. See the bugreport for further details.

Update: After some criticism from MySQL (see comments) I decided to disable the patch in the default builds with the next upload, but still ship it in the source package.

Today I uploaded an updated backport of the linux-2.6 package. It's based on 2.6.22-6, which was the last 2.6.22 series kernel available in Debian unstable, and includes the upstream patches from 2.6.22.12 (2.6.22.12-rc1 was included in 2.6.22-6) up to 2.6.22.18 (the user pointer access fix in get_iovec_page_array(), main reason for this update), and an update to the latest vserver patch.

MySQL 5.0.51a was released today, which is a security hotfix release without any new features compared with 5.0.51. It fixes CVE-2007-6303, CVE-2007-6304, CVE-2008-0226 and CVE-2008-0227. These problems are already fixed in Debian with 5.0.32-7etch4 and 5.0.32-7etch5 for stable and 5.0.45-5 and 5.0.51-3 for unstable using the patches from MySQL, hence no need to write bugreports against the MySQL packages asking for an update to 5.0.51a.

We will update to 5.0.51a anyway with the next upload, but there's no need to hurry.

Due to lack of time and interest these packages are up for adoption: dog (bugs), lslk (bugs), nast (bugs), newsgate (bugs), nullmailer (bugs) and pyblosxom (bugs).

Drop me a mail if you're interested in taking over one of these packages.

Yesterday in the evening I uploaded MySQL 5.0.51-1 to Debian unstable. Unfortunately it took a bit longer to prepare the updated package than expected, mainly because 5.0.51 wasn't MySQL's best relase, and I had to backport and include some fixes from 5.0.52 and 5.0.54 to get it working (see the changelog for details). Then I had to wait a few more days until 5.0.45-5 got into testing before I could finally upload 5.0.51-1 to unstable.

The most important changes are:

• Testsuite is now enabled during build process, which requires some time, but it ensures that everything is fine with the build. I already found two gcc 4.2.x related bugs in 5.0.51 which were fixed before 5.0.51-1 was uploaded to Debian.
• Manpages re-added, MySQL AB has put them under the GPL so we could include them again after we had to remove them a few months ago.

Regarding the Community vs. Enterprise decision I had a discussion with Kaj Arn , Lenz Grimmer, Daniel Fischer and Monty Taylor on IRC last week and we decided to stay with the Community Edition in Debian for now, and see what the future will bring us.

If you're interested in the MySQL packages in Debian, join #debian-mysql on OFTC. Most people involved into the packages are hanging around there.

Last week I wrote about CVE-2007-5925, a vulnerability in MySQL 5.0.51 (current version of the MySQL Community Edition), which is fixed in 5.0.52 (current version of the MySQL Enterprise Edition, released on the same day as 5.0.51) and was known for more than three weeks when 5.0.51 got released. 5.0.51 is also affected by CVE-2007-6303 and CVE-2007-6304, both as well already fixed in 5.0.52. While preparing 5.0.51-1 (not yet uploaded to unstable) for Debian, I stumbled upon another problem.

The testsuite (which fails to run as root in 5.0.51 and earlier, also fixed in 5.0.52) fails during the mysqlcheck test. This bug is fixed in 5.0.52 as well, but it took me a while to find the problem in 5.0.51 and create a patch. I still need to find and fix the problem with 5.0.51 when running the testsuite as root.

Conclusion: Switching to the Enterprise Edition in Debian would make my life much easier, at least when comparing 5.0.51 and 5.0.52. I'll think about it...

Last week I wrote about a known vulnerability in MySQL 5.0.51 (the current Community release), which is fixed in 5.0.52 (the current Enterprise release, which was released on the same day as 5.0.51) and was known for more than three weeks when 5.0.51 was released. While preparing 5.0.51-1 (not yet uploaded to unstable) for Debian, I stumbled upon another problem. The testsuite (which fails to run as root in 5.0.51 and earlier, also fixed in 5.0.52) failed during mysqlcheck test.

This bug is fixed in 5.0.52 as well, but it took me a while to find the problem in 5.0.51 and create a patch. I still need to find and fix the above mentioned problem when running the testsuite as root.

Conclusion: Switching to the Enterprise release in Debian would make my life much easier, at least when comparing 5.0.51 and 5.0.52. I'll think about it...